1. Field of the Invention
The present invention relates to telecommunications systems and, more particularly, to a method and system for providing account balance or prepaid communication service.
2. Description of Related Art
For many years, the telecommunications industry has recognized the need to provide a mechanism for restricting or otherwise managing use of communication services based on a measure of subscriber account balance. In systems providing account balance services, a subscriber may first establish a prepaid account with a service provider and then pay for a duration of communication services on the communication network by adding money to the prepaid account. An account balance typically represents a measure, such as time or monetary value, of communication services that a subscriber is authorized to use. As the subscriber uses the service, the carrier may then continuously monitor and decrement the balance of the prepaid account. When the balance drops to a low threshold level, the service provider may notify the subscriber and allow the subscriber to add more money to the account. Further, once the account is exhausted, i.e., the balance drops to zero, the service provider may refuse to provide additional services to the subscriber or charge the subscriber for an excess use. Other arrangements are also possible.
Offered for years in both landline and wireless systems, prepaid service has been viewed as a tool to attract “credit challenged” consumers, that is, potential customers with poor credit histories or who otherwise lack adequate credit references. In addition, prepaid services appeal to consumers who do not want to be burdened with contracts and bills, who want to maintain fixed budgets, or who simply wish to remain anonymous. For example, travelers who require a temporary phone service can benefit from prepaid services in the form of a rented wireless phone that has been activated with prepaid minutes. Similarly, a pre-activated wireless phone with initial prepaid minutes can be given, sold or rented through various channels, including supermarkets and convenience stores.
The concept of account balance services, however, encompasses more than just traditional prepaid communications. In general, an account balance service can involve establishing or applying any type of account balance that serves as an actual or suggested limit on use of communications services. The account balance could represent a time limit such as minutes of use, or a monetary limit such as dollars of use, for example. Further, the account balance that defines the actual or suggested limit on use need not necessarily come from a prepayment by a subscriber or other party. Rather, the account balance could simply represent an assigned limit on use, which the subscriber may or may not be allowed to exceed.
In order to provide account balance services, a telecommunications network should include some mechanism to track the start and stop of calls, to monitor and adjust a subscriber's balance during a call, and to maintain control in order to facilitate an appropriate response to a low or zero balance.
FIG. 1 illustrates a wireless telecommunication network 100 in which account balance services are provided according to one existing embodiment. As shown in FIG. 1, network 100 includes a first client device 102, which communicates over an air interface 106, an intermediate base station 104, and a communication link 108 with a Base Station Controller (“BCS”) 152. According to the embodiment illustrated in FIG. 1, first client device 102 may be a cellular telephone, for instance. BSC 152 is in turn coupled via a communication link 154 to a mobile switching center (“MSC”) 110, which serves to connect calls between various points in network 100. As shown in FIG. 1, MSC 110 is connected by a voice data link 112 to a public switched telephone network (“PSTN”) 114, which provides a path through which MSC 110 may connect calls with a remote MSC 118 and in turn with a second client device 126. MSC 118 is interconnected via a BSC 164 and an intermediate base station 122 to second client device 126.
Exemplary network 100 includes a signaling subsystem, which may be a packet-switched SS7 signaling system, for instance. At the core of the signaling network, there is a signal transfer point (“STP”) backbone network 134, which may consist of one or more signal transfer points and associated signaling paths. STP network 134 carries out-of-band signals that are used to control the switches and to set up and tear down the circuit between the calling party, such as first client terminal 102, and the called party, such as second client terminal 126. As illustrated in FIG. 1, MSC 110 and MSC 118 are coupled to STP network 134 via signaling paths 128 and 132, respectively. For instance, Signaling System 7 (“SS7”) may be used as a signaling system.
STP network 134 is coupled to a centralized service control point (“SCP”) 142 via a signaling path 140. SCP 142 contains control information and call processing logic to assist MSC 110. For example, SCP 142 may provide routing instructions to MSC 110. In exemplary network architecture 100, an Intelligent Peripheral (“IP”) 162 is coupled to STP 134 via a signaling path 160, and MSCs 110 and 118, or HLR 138 and SCP 142 may communicate with IP 162 via STP 134. IP 162 can be arranged to provide assorted services, including tone generation, voice recognition, playback, compression, call control, recording, and DTMF detection and collection. IP 162 may also include an intelligent voice response unit (“IVRU”) to facilitate various interactions with users. In such an embodiment, IP 162 may be linked to one or more MSCs via one or more voice trunks, such as a voice trunk 130 illustrated in FIG. 130 for MSC 118. It should be understood that MSC 110 may have a voice trunk to the IP 162 as well. Typically, IP 162 does not have call control logic embedded and must be instructed to perform each operation under the control of SCP 142 using a Transmission Control Protocol/Internet Protocol (“TCP/IP”), for instance.
Exemplary network 100 further includes a Home Location Register (“HLR”) 138 coupled by a signaling path 136 with STP network 134. HLR 138 serves standard functions in the wireless network such as managing service profiles and authenticating subscribers or mobile stations. HLR 138 may be located on an SCP operated by the home service provider of record for a given subscriber. In addition, network 100 may include a Visitor Location Register (“VLR”), which stores service profile information for mobile stations being served by the carrier-operating SCP 142.
To manage account balances, network 100 further includes a calculation engine (“CE”) 146. Calculation engine 142 is a programmed computer running an application to manage subscriber account balances. In FIG. 1, CE 146 is coupled to SCP 142 via a link 144. Link 144 may be a wide area network such as the Internet, and SCP 142 and CE 146 may communicate over link 144 by a TCP/IP interface.
In one arrangement for providing account balance services, a prepaid subscriber may originate a call from first client device 102 by sending dialed digits to MSC 110. Upon receipt of the dialed digits, MSC 110 may request instructions from SCP 142 by sending to SCP 142 an origination request message including the dialed digits and a mobile station identifier of first client device 102. Upon receipt of the dialed digits, SCP 142 may determine that the subscriber is the account balance service subscriber, and, further, that IP 162 needs to play an announcement of the subscriber's available balance. Therefore, SCP 142 may request from IP 162 a routing number for routing the call from MSC 110 to IP 162. IP 162 may respond by allocating a temporary number to one of its ports and returning that number to SCP 142. SCP 142 may then send a message to MSC 110, instructing MSC 110 to set up a call to the allocated number at IP 162, and MSC 110 may then set up the call.
Once the call is set up between MSC 110 and IP 162, IP 162 may query SCP 142 for instructions, and SCP 142 may instruct IP 162 to play a balance announcement. EP 162 may then play the balance announcement to the user at first client device 102 and may inform SCP 142 it has done so. In turn, SCP 142 may send a disconnection request to MSC 110 instructing MSC 110 to disconnect from IP 162.
In such an embodiment, MSC 110 may then set up a call to a number dialed by the subscriber and, when the called party answers, MSC 110 may detect an answer trigger and responsively sends to SCP 142 a message indicating that the call was answered. Upon receipt of the message, SCP 142 may instruct CE 146 to begin decrementing the subscriber's account balance. In turn, when the call ends, MSC 110 may detect a disconnection trigger and responsively may send to SCP 142 a disconnection message to SCP 142 that responsively may instruct CE 146 to stop decrementing the subscriber's account balance.
This solution for providing account services is expensive, since it requires MSCs and SCPs to be configured with call triggers that trigger the MSCs and SCPs to interact with network entities providing account balance services, such as CE 146 and IP 162. Further, existing systems require costly overlay voice connectivity to the network entities providing account balance services (such as voice connectivity between MSC 110 and IP 162 explained above in greater detail) and, thus, consume voice connection resources by tying voice trunks available on network entities in the network.
Therefore, a need still exists for an improved system and methods for providing account balance services.